本篇是故事四的「內化」篇。
本篇要回答：不因噎廢食、也不再裸奔——自動修正要怎麼用，才能既省力又不出事？
Day 19 排除了兩種偷懶結論（怪工具、禁工具）之後，剩下的工作是把「人負責語意」這句話落成可執行的檢查表——否則它會退化成另一句「下次注意」。
我曾以為自動化的重點是「省掉人工」。修正後的版本是：自動化的重點是把人工移到只有人能做的位置。格式排版、import 排序，機器全權處理；查詢語意、資料契約，機器產出、人來驗收。省力與安全的分界線，就是「這個改動需不需要理解系統語意」。
自動修正安全檢查表，每條附驗證方式：
| 措施 | 驗證方式 |
|---|---|
| formatter、一般 lint fix、unsafe fix 分成三批獨立執行 | 各自產生獨立 diff 與 commit，可單獨回退 |
| 工具升級時檢查規則變更、先跑預覽 diff | 升級 PR 附規則變更摘要與空 diff 證明 |
| 自動修正後必須 review diff 才能合併 | 流程上自動 commit 不得直達主幹 |
| ORM 查詢建立結果導向回歸測試（斷言查詢結果，不只斷言不拋例外） | 在測試庫植入已知資料，改壞條件時測試轉紅 |
| 語意敏感目錄（ORM、DSL）排除特定規則或整批 unsafe fix | 設定檔可查、CI 驗證設定生效 |
| 疑難案例比對產生的 SQL | 開發環境保留 SQL echo／log 的開關 |
| CI 同時執行 lint、型別檢查與行為測試 | 三者缺一 CI 即紅 |
| 工具版本與設定納入版控 | 兩台機器跑同一命令產生相同結果 |
這張表對照 Day 19 的促成因素逐條可回溯：每一項措施都對應至少一個促成因素，沒有孤兒措施，也沒有漏網因素——這是檢查表不淪為儀式的最低標準。
區分證據等級。已確認事實：表中機制皆為現行工具鏈可實作的標準能力。合理推論：全表落地後，同型事故要嘛在 diff review 被攔，要嘛在回歸測試轉紅——兩道獨立防線。執行假設：團隊接受自動修正分批帶來的流程成本。
工具規則通過，不代表領域語意仍然成立。
把程式碼修得更像標準 Python 很容易；證明它仍然是正確的 ORM 查詢，才是我們不能外包給格式規則的工作。
故事四到此收束。下一個故事（Day 21 起）走進分散式的完成語意：Pub/Sub 都非同步了，你還要我立刻回答指令成功沒？
iThome鐵人賽
看影片追技術